More fixes to 5107R

The hunt for the "final five" continues.

No, the hunt for the "final five" is not a reference to the reimagined Battlestar Galactica series. It's the final five percent of a running project. Up to 95% "completness" things usually go pretty well. But the last five percent drag on endlessly.

It's like with the construction of my new house. Since January I'm saying "Two more months and I can move in."

With BlueOnyx 5107R it's not different, hence it's still labled as "Beta".

The OS templates for 5107R were a total train wreck for example. Sure, you could create a VPS with them. But then they started to bugger out on Vsite creation. After a two day bughunt I finally remembered why: /home needs to be a separate partition and CODB needs a "Disk" object for the partition "/home". Even if there is no real /home partition - like in an OpenVZ VPS.

So on 5106R OS templates we had this small add on script in the RPM "nuonce-solarspeed-vbq-constructors", which populated CODB with a "Disk" object that faked the presence of a /home partition. As I wanted 5107R to be flexible enough to run the same unmodified code from a CD install as well as inside an OS template, I had decided to drop the RPM "nuonce-solarspeed-vbq-constructors" and merge the bare metal required code into the stock 5107R codebase with the needed IF clauses that check if this is a VPS or not. But yeah, the fake /home partition stuff was missing.

After testing it out by modifying an existing OS template that I already had downloaded, I could create Vsites just fine in my test VPS. So I built a new OS template, downloaded it, created another test VPS off it and tried to create a site.

And I got the same bloody error!

After another couple of hours of frustrated poking around, I discovered that I could create a Vsite by manually combining the two separte CODB transactions that are usually involved. But if I used the GUI to create the first Vsite, then it buggered out. Creating the Vsite manually and deleting it would then allow the GUI to work just fine. I'm still stumped why that's the case.

This needs to get looked into and I'm sure the solution to it (the real one, not a work around!) is something really simple. But I can't see yet what it might be. So in the meantime I just created another OS template which has a script that you won't find on the CD version. This constructor creates a Vsite and deletes it when CCEd is started for the first time and while the initial setup wizard has not yet run. That's a shameless and dirty work around - I know. But it'll have to do for now, just to get things moving ahead.

Likewise this script also solves three other glitches that the OS template version of 5107R had:

Upon initial booting the Network was dead and Apache refused to work. Beyond that: If the initial "dummy" site was deleted, venet0:0 dissapeared, because it didn't have the "real" flag set in CODB. The "real" flag makes sure that a network interface is not removed, if the last site on it is deleted.

I fixed this by allowing our "dirty fix" constructor to set the "real" flag for "venet0:0" and by restarting both the network and Apache after it was done with creating and removing our dummy Vsite.

Other than that: Our base-java.mod is now at a point where it works. You can finally upload WAR files as well, which was previously broken. Thanks to Christoph for the testing and for finding these bugs!

Another big thank you goes to Rickard, who contributed an updated base-swupdate.mod, which allows you to view, to modify and to add YUM repositories through the GUI. I released it to the 5107R YUM repository and the 5106R version will also be out soon.